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Introduction 


Overview 

This  is  an  interim  progress  report  concerning  the 
exploratory  development  of  a  combat  emergency  medicine  expert 
system  (CEMES).  The  work  presented  in  this  report  documents 
the  Phase  I  exploratory  development  of  CEMES  conducted  from 
November  1985  to  August  1986.  The  CEMES  project  is  the  core 
effort  within  the  artificial  intelligence  research  program 
being  conducted  at  the  U.S.  Army  Aeromedical  Research 
Laboratory. 1 

The  theoretical  background  and  feasibility  analysis  for 
the  CEMES  project  was  completed  in  September  1985  under  the  In- 
House  Laboratory  Independent  Research  (ILIR)  program  and 
documented  in  Landon  (1986).  The  feasibility  study  outlined 
the  concept  development  underlying  the  CEMES  project  in 
addition  to  providing  a  general  review  of  artificial 
intelligence  and  existing  medical  expert  systems. 

CEMES*  Phase  I  is  documented  in  two  separate  reports. 

This  report  outlines  the  rationale,  general  operation,  and 
specific  design  concepts  underlying  the  CEMES  project.  A 
second  report  (Landon,  1987)  documents  the  CEMES  programs  and 
program  code.  The  second  report  exists  primarily  for  archival 
purposes  and  is  not  required  for  reference  when  reading  this 
report . 

Military  relevance 

Army  21  operational  doctrine  anticipates  a  complex,  fluid, 
and  chemical,  biological,  and/or  radiological  (CBR) 
contaminated  battlefield  expected  to  produce  mass  casualties. 
The  expertise  of  physicians  and  other  medical  personnel  will  be 
needed  at  all  battlefield  levels  to  reduce  medical 
complications  and  prevent  avoidable  deaths.  However,  the 
nature  of  the  battlefield  and  anticipated  lack  of  numerical 
superiority  in  both  land  and  air  forces  may  prevent  quick  and 
efficient  casualty  evacuation.  Rapid  and  expert  care  will  be 
necessary  for  casualty  survival  and  potential  return  to  duty. 
Lack  of  personnel  will  make  it  unfeasible  to  assign  the 
required  numbers  of  physicians  at  all  battlefield  levels  as 
necessary  to  provide  the  appropriate  medical  care.  In 


1  DD  Form  1498,  Artificial  Intelligence  and  Robotics: 
Biomedical  Applications,  Project  Number  3E16277A879,  Work  Unit 
Number  167.  Protocol  titled  "Investigation  and  Exploratory 
Development  of  Medical  Expert  Systems  for  Military 
Applications"  dated  22  March  1985  and  approved  19  July  1985. 
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addition,  casualties  among  medical  personnel  would  aggravate 
the  effects  of  mass  casualty  situations. 

The  Medical  Systems  Program  Review  (Robertson  and  Glazier, 
1985)  outlined  a  new  battlefield  medical  care  strategy.  This 
strategy  included  a  continuum  of  care  from  the  forward  line  to 
the  continental  United  States.  A  casualty  would  "flow”  through 
the  continuum  only  so  far  as  his  injury(s)  dictated  and  then  he 
would  be  returned  to  duty  as  soon  as  possible.  Combined  with 
the  continuum  of  care  was  the  idea  of  far  forward  care,  where 
first  aid  and  trauma  care  would  be  administered  as  far  forward 
in  the  continuum  of  care  as  possible.  Technological  advances 
in  emergency  medicine  would  enhance  the  implementation  and 
effectiveness  of  the  continuum  and  far  forward  care  concepts. 

Artificial  intelligence  has  been  designated  as  one  of  the 
Army's  major  research  and  development  thrust  areas, 2  with 
artificial  intelligence-based  medical  systems  a  major  subarea. 3 
Although  medical  expert  systems  have  been  developed  and  used 
for  academic  research,  there  have  been  few  attempts  at 
developing  this  technology  for  military  medical  applications. 
The  likelihood  of  successful  attainment  of  the  medical  and 
health  care  mission  could  be  enhanced  through  artificial 
intelligence  systems  that  both  diagnose  and  treat  casualties. 

In  addition,  a  properly  designed  and  implemented  medical  expert 
system  could  bring  to  the  battlefield  health  care  capabilities 
currently  available  only  from  specialists  in  rear  echelon 
facilities.  Such  systems  also  could  serve  as  aids  to 
physicians  during  peacetime. 


2  The  Militarily  Critical  Technologies  List,  Office  of  the 
Under  Secretary  of  Defense,  Research,  and  Engineering, 
Washington,  D.C.,  October  1985,  paragraph  1.3.3. 

3  Combat  Service  Support  Mission  Area  Analysis  -  Level  II, 
Vol  1:  Executive  Summary,  January  1  9 8 3 »  pages  I4a-I4b, 
paragraph  15.  Also  see  the  study  on  artificial  intelligence  by 
the  National  Research  Council  (1983). 
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System  concept 


Background 

Artificial  intelligence  (AI)  is  a  term,  first  coined  in 
1956  by  John  McCarthy,  used  to  refer  to  the  subarea  of  the 
cognitive  sciences  devoted  to  the  attempt  to  program  computers 
to  perform  tasks  usually  thought  of  as  requiring  some  measure 
of  intelligence  (indicated  by  a  human’s  unique  ability  to 
accomplish  the  same  task).  General  research  in  AI  has  resulted 
in  the  technological  capability  for  producing  limited  domain, 
but  sophisticated,  problem  solving  programs.  These  programs 
are  known  collectively  as  expert  systems  because  they  attempt 
to  duplicate  or  emulate  human  expert  abilities  within  some 
well-defined  domain. 

The  specific  design  and  implementation  of  any  particular 
expert  system  is  unique  to  that  system.  The  technical  aspects 
of  general  expert  system  design  were  reviewed  in  the  CEMES 
feasibility  study  (Landon,  1986).  The  specific  design  aspects 
of  CEMES  are  covered  in  this  report. 

CEMES  medical  domain  of  operation 

CEMES  task  domain  is  emergency  medicine  diagnosis  and 
treatment  of  casualties  with  respect  to  hemorrhagic  shock  and 
related  cardiovascular  problems  prior  to  receiving  definitive 
care.  The  importance  and  critical  nature  of  hemorrhage  and 
shock  with  respect  to  the  morbidity  rate  of  casualties  was 
pointed  out  by  Bellamy  (1984)  in  an  analysis  of  the  causes  of 
death  in  conventional  land  warfare: 

wFirst  and  foremost,  there  is  a  need  to  improve  the  field 
management  of  hemorrhage.  The  combination  of  simple  first 
aid  measures  plus  infusion  of  an  oxygen-carrying  solution 
and/or  use  of  pharmacologic  interventions  designed  to 
optimize  cardiac  output  (antishock  drugs)  might  be 
lifesaving  in  a  surprisingly  large  number  of  casualties.” 
(pg.  61) 

The  primary  objectives  in  emergency  medicine  are 
resuscitation  and  stabilization  pending  a  complete  diagnosis 
and  determination  of  disposition  later.  Initial  resuscitative 
measures  and  battlefield  first  aid  must  be  accomplished  by  the 
platoon  medic,  medic  extender,  or  a  physician.  The  extensive 
hands-on  requirements  for  first  aid  measures  preclude  the  use 
of  an  automated  system  ( i. e. .  although  great  advances  have 
occurred  in  robotics,  a  robotic  hand  with  the  sensitivities  and 
dexterity  of  the  human  hand  has  yet  to  be  devised).  However, 
once  a  casualty  is  attached,  an  automated  system  could  provide 
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limited  aid  to  a  physician  or  medic  in  any  future  resuscitative 
measures  that  might  be  required* 


CEMES  is  designed  to  provide  the  casualty  care  management 
required  to  reduce  morbidity  rates  due  to  hemorrhage  and  shook , 
Specifically,  CEMES  manages  IV  fluid  infusion  and  periodic  or 
continuous  drug  treatments  based  on  casualty  condition.,  The 
system  monitors  vital  and  other  signs  and  establishes  trends 


bai 


on  those  measures  both  to  guard  against  and  warn  of 


catastrophic  or  gradual  deterioration  in  condition,  CEMES  also 
maintains  a  medical  history  record  for  later  examination  to  aid 
in  a  complete  diagnosis  and  determination  of  disposition  at  a 
definitive  care  facility. 


CEMES. military  operational  requirements 


The  prevalent  operational  environment  for  CEMES  is 
dictated  by  military  requirements*  Following  military  doctrine 
(Department  of  the  Army,  FM  100-5,  FM  8-10;  Cook,  1984; 
Robertson  and  Glazier,  1985),  several  operational  and 
environmental  assumptions  that  have  governed  the  design  of 
CEMES  are: 


1 .  The  system  should  be  capable  of  operating  within  a  CBR 
contaminated  battlefield,  requiring  diagnosis  and  treatment  of 
CBR  contaminated  casualties. 


2.  Expendable  supplies  ( e . g . f  IV  fluid)  may  be  extremely 
limited,  placing  a  high  value  on  economy  of  supply  use  and 
efficient  treatment  strategies. 

3.  Qualified  maintenance  personnel  may  not  be  present, 
requiring  the  system  to  be  self-diagnosing  to  compensate  for 
damaged  or  inoperative  subassemblies  ( i . e . .  degraded  mode 
operation ) , 

4.  Immediate  casualty  evacuation  will  not  necessarily  be 
available,  requiring  long-term  casualty  care  up  to  48  hours. 

Although  the  above  four  operational  assumptions  are  not 
exhaustive,  they  cover  the  major  aspects  of  design  that  are 
somewhat  unique  to  the  military.  The  implications  of  these 
requirements  for  CEMES*  design  were  examined  in  the  feasibility 
study  (Landon,  1986). 

It  is  anticipated  that  CEMES  could  be  deployed  as  far 
forward  as  the  battalion  aid  station.  A  CEMES  unit  could 
function  in  a  multicasualty  mode,  where  a  single  CEMES  system 
monitors  several  casualties,  or  in  a  single  casualty  mode, 
where  each  casualty  has  a  unique  CEMES  unit.  The  latter  ease 
is  more  likely.  That  is,  a  single  casualty,  battery-operated 
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CEMES  unit  could  be  incorporated  into  a  stretcher  or  other 
suitable  transport  device  and  be  evacuated  with  the  casualty 
until  definitive  care  is  reached.  Add-on  modules  could  provide 
increasingly  sophisticated  medical  capabilities  as  the  casualty 
moves  through  the  evacuation  system,  possibly  to  the  point  of 
providing  the  casualty  with  his  own  personalized  mobile 
critical  care  unit. 

Q  h  1 1 1  n  &  -&&-..££  JLlan 

One  of  the  central  design  concerns  for  CEMES  is  closed- 
loop  operation.  Closed-loop  expert  systems  are  defined  as 
systems  that  require  little  or  no  human  intervention  to 
accomplish  their  objectives.  For  an  emergency  medicine  expert 
system,  this  means  diagnosis  and  treatment  (or  at  least  the 
suggestion  of  a  comprehensive  treatment  regimen)  of  emergency 
medical  conditions  is  accomplished  primarily  by  the  expert 
system.  Literally  interpreted,  closed-loop  operation  requires 
the  system  operate  either  in  the  absence  of,  or  in  lieu  of,  an 
attending  physician,  possibly  with  a  human  assistant  serving  to 
aid  the  system  by  attaching  biomedical  sensor/monitoring 
equipment  and  replacing  expendable  supplies.  However,  CEMES  is 
being  designed  for  the  more  conservative  and  realistic  purpose 
of  serving  as  a  sophisticated  assistant.  CEMES  is  designed  to 
decrease  physician  or  medic  workload  by  having  some  elements  of 
autonomy  and  not  requiring  continuous  human  interaction. 

The  closed-loop  aspect  of  CEMES  operation  is  implemented 
in  a  process  control  loop  (which  will  be  explained  more 
completely  in  the  section  "The  CEMES  expert  system").  To 
provide  a  preliminary  overview,  the  major  processing  events  in 
the  CEMES’  closed-loop  cycle  are: 


1.  CEMES  first  obtains  whatever  data  is  available  either 
automatically  through  noninvasive  biomedical  sensors  attached 
to  the  casualty  or  through  querying  an  attending  medic  or 
physician.  CEMES  will  query  an  attending  medic  or  physician 
only  when  required  due  to  an  inability  to  obtain  a  unique 
diagnosis  using  the  biomedical  sensor  data.  This  design 
consideration  aids  in  workload  reduction  by  not  requiring 
attending  personnel  to  continually  monitor  the  system. 

However,  the  medic  or  physician,  when  desired,  can  query  the 
system. 


2.  Following  data  collection,  CEMES  determines 
diagnosis  with  respect  to  shock  or  related  cardiovasc 
problems  and  develops  a  treatment  recommendation  base 
diagnosis.  CEMES  treatments  currently  are  limited  to 
infusion  and  a  small  set  of  drugs  that  can  be  adminis 
intravenously  through  the  IV  line  ( e . g . .  antishock  ag 
atropine).  The  final  IV  infusion  rates  and  drug  trea 


a 
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determined  later  in  the  cycle  based  on  trend  and  logistical 
analyses  in  addition  to  the  current  diagnosis. 

3.  Following  the  diagnosis,  CEMES  examines  the  casualty’s 
vital  sign  history  for  trends.  The  trend  analysis  can  have 
three  directions  (improving,  deteriorating,  or  unchanging)  and 
two  magnitudes  (catastrophic  and  gradual)  for  a  total  of  five 
trend  outcomes. 4  Trends  are  established  both  by  examining 
directionality  of  vital  signs  over  time  and  by  relationships 
between  consecutive  diagnoses  over  time.  For  example,  class 
three  hemorrhagic  shock  obviously  is  worse  than  class  one 
hemorrhagic  shock,  and  so  a  casualty  that  jumps  to  class  three 
shock  directly  from  class  one  shock  is  deteriorating  rapidly, 
CEMES  recognizes  these  relationships  and  takes  appropriate 
actions  based  on  them. 


k.  The  logistical  analysis  involves  determination  of  IV 
fluid  and  line  status,  amount  of  fluid  remaining,  and 


anticipated  need  based  on 
the  treatment  recommended 
IV  fluid  infusion  when  no 
logistical  analysis  traps 
necessary  messages  to  the 
line,  and  inhibits  other 


current  infusion  rate.  For  example, 
by  the  current  diagnosis  may  require 
IV  line  has  been  established.  The 
this  potential  problem,  provides  the 
medic  or  physician  to  establish  an  IV 
CEMES  systems  from  assuming  that  an 


appropriate  treatment  is  being  administered  until  an  IV  line 
has  in  fact  been  established.  The  logistical  analysis  also 
watches  for  low  fluid  conditions  in  IV  bags,  inoperative 
sensors,  and  other  logistically  based  conditions. 


5.  CEMES  concludes  an  operation  cycle  by  establishing  a 
treatment  (  i .,  e .  .  IV  fluid  infusion  rate),  updating  the  casualty 
history,  and  providing  the  appropriate  signals  to  the 
biomedical  hardware  to  effect  the  actions  CEMES  has  determined 
are  necessary.  CEMES  then  recycles  after  a  1  minute  real-time 
interval , 


^  The  unchanging  trend  direction  has  no  magnitude 


Phase  I  development  status 


The  major  Phase  I  objective  was  to  develop  CEMES 
sufficiently  to  perform  diagnoses  and  treatment  suggestions  for 
cardiovascular  conditions  based  on  blood  pressure  and  heart 
rate  assuming  ideal  conditions  f i . e . .  no  degraded  modes)  and  no 
CBR  contamination.  That  is,  to  provide  a  system  that  works 
with  respect  to  its  major  design  objectives. 

CEMES  has  been  developed  to  the  extent  of  demonstrating 
the  concept  of  closed-loop  diagnosis  and  treatment.  The  system 
uses  blood  pressure,  heart  rate,  and  respiration  rate  that  are 
manually  entered  through  a  menu-driven  front-end.  CEMES 
currently  is  able  to  complete  full  operational  cycles 
indefinitely,  so  long  as  the  vital  sign  data  are  entered  when 
required.  CEMES  diagnoses  hemorrhagic  shock  and  related 
cardiovascular  problems,  displays  appropriate  IV  infusion 
treatments  and  rates  for  conditions  of  shock,  maintains  a 
casualty  medical  history,  and  manages  IV  logistics,  A  color 
graphics  display  is  used  to  present  the  state  of  the  casualty 
and  system  as  determined  by  CEMES. 

At  this  interim  stage,  CEMES  is  designed  to  operate  in  a 
pure  closed-loop  fashion.  That  is,  the  operator  is  totally 
passive,  entering  the  values  of  the  signs  at  the  appropriate 
times  and  thereby  simulating  the  collection  of  data  assumed  to 
be  available  through  automatic  biomedical  sensors.  Human 
operator  query  and  response  are  not  yet  available.  It  is  fully 
realized  that  diagnosis,  particularly  of  hemorrhagic  shock,  is 
often  dependent  on  qualitative  signs  such  as  capillary  fill, 
mental  state,  skin  color,  the  presence  of  obvious  serious 
wounds,  etc.,  that  may  require  an  operator’s  interactive  input. 
Those  type  of  inputs  will  be  addressed  in  Phase  II.  The 
primary  Phase  I  goal  was  to  demonstrate  the  core  closed-loop 
concept  of  CEMES  as  an  initial  effort. 
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CEMES  general  design 


go  n  g  e  p.t  u_ a  i ,  o  r  ft  a  a  i  za.t.  1  an 

The  conceptual  organization  of  CEMES  is  shown  in  Figure  1 . 
This  conceptual  organization  partially  was  developed  in  the 
feasibility  study,  but  reflects  some  changes  required  during 
the  exploratory  development  of  CEMES.  CEMES  is  organized 
around  a  blackboard  (Erman  and  Lessor,  1975;  Hayes-Roth,  1985) 
which  is  a  shared  data  structure  accessible  to  all  of  the  CEMES 
subsystems.  The  core  of  CEMES  consists  of  the  diagnostics, 
trend,  and  management  subsystems.  These  three  subsystems 
comprise  the  main  expert  system  responsible  for  governing 
CEMES*  operation.  The  core  expert  system  completes  the 
diagnosis,  constructs  the  IV-based  treatment  regimen,  watches 
for  trends,  and  manages  the  general  operation  of  the  entire 
system.  The  diagnostics,  trend,  and  management  subsystems  are 
directly  analogous  to  the  knowledge  sources  used  in  a  standard 
blackboard-based  system,  obtaining  input  from  and  recording 
output  on  the  blackboard.  These  three  subsystems  and  their 
operations  as  an  expert  system  will  be  explained  in  depth  in 
the  section  "The  CEMES  expert  system." 


FIGURE  1 .  CEMES  conceptual  organization. 


Figure  1  also  diagrams  two  subsystems  that  have  not  been 
designed  and  programmed  for  Phase  I,  but  require  brief 
explanations.  These  are  the  sensor  and  effector  subsystems. 

The  sensor  and  sensor  status  subsystem  includes  the  necessary 
hardware  and  software  for  sensing  and  translating  biomedical 
signals  along  with  providing  information  concerning  the 
integrity  of  the  front-end  sensor  ensemble.  Some  of  this 
technology  now  is  available  in  off-the-shelf  medical 
equipment. 5  The  available  equipment  usually  includes  the 
necessary  algorithms  for  translating  the  raw  signals  into  some 
standard  or  useful  form  along  with  being  able  to  sense  improper 
transducer  attachment  and  simple  malfunctions. 

The  effector  and. effector  status  subsystem  consists  of  the 
appropriate  hardware  and  software  to  govern  electronically 
controlled  IV  fluid  flow  administrators.  Its  primary  function 
is  as  a  delivery  mechanism  for  IV-based  treatment  regimens. 

This  type  of  equipment  is  available  and  includes  capabilities 
for  sensing  blockages  and  other  malfunctions  in  IV  fluid 
delivery. 

Laboratory  equipment 

The  exploratory  development  of  CEMES  is  being  conducted 
using  a  Hewlett-Packard  (HP)  9000,  Model  520,  general  purpose 
minicomputer  (see  Appendix  A)  with  the  HP  BASIC  operating 
system,  and  a  Symbolics  3640  standalone  LISP  machine  (see 
Appendix  A)  with  the  Symbolics  LISP  operating  system.  Figure  2 
provides  a  diagram  showing  the  relationship  between  these 
computers,  various  other  CEMES  equipment,  and  the  CEMES 
subsystems  shown  in  Figure  1. 

The  core  expert  system  portion  of  CEMES  is  programmed  in 
LISP  on  the  Symbolics  3640  LISP  machine.  The  LISP  language  was 
selected  due  to  its  close  connection  with  artificial 
intelligence  development  and  the  object-oriented  programming 
style.  However,  the  LISP  machine  and  the  LISP  language  do  not 
provide  good  mechanisms  for  real-time  input/output.  LISP  was 
designed  as  and  is  best  used  as  a  very  high  level  programming 
language.  Since  it  also  is  a  highly  interactive  language, 
real-time  oriented  mechanisms  certainly  exist  in  the  language. 
However,  it  was  felt  real-time  signal  analysis  and  other  front- 
end  functions  were  best  left  to  equipment  and  languages  better 
designed  for  those  functions.  Therefore,  the  core  expert 


5  This  off-the-shelf  equipment  probably  will  need  to  be 
modified  and  hardened  to  meet  military  specifications  for  a 
fieldable  CEMES  system.  There  are  other  equipment  requirements 
that  are  not  available  off-the-shelf  which  will  be  documented 
in  the  CEMES  final  report. 
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FIGURE  2.  Laboratory  equipment  and  CEMES  subsystem 
relationships . 


system  uses  a  front-end  programmed  in  basic  on  the  HP  9000 
minicomputer  to  facilitate  real-time  input/output  operations. 

In  addition,  the  HP  9000  provides  the  operator  interface 
functions  and  the  necessary  communications  capabilities  for  the 
CEMES'  graphic  display  and  sensor / treatment  operations.  The  HP 
6942A  multiprogrammer  (see  Appendix  A)  provides  the  required 
analog-to-digi tal ,  digi tal- to- analog ,  and  other  hardware  and 
software  functions  for  interfacing  off-the-shelf  biomedical 
sensors,  simulators,  IV  units,  etc.,  to  the  CEMES  computers. 

Derailed  design  chart  and  design  methodology 

A  detailed  organizational  master  chart  of  CEMES  is 
provided  in  Figures  3a  and  3b.  The  charts  in  Figures  3a  and  3b 
break  down  CEMES*  organization  in  terms  of  equipment, 
subsystem,  subsystem  communications  and  information  flow,  and 
central  aspects  of  the  programming  design  of  each  subsystem. 

The  actual  flow  charts  and  code  for  each  subsystem  are 
documented  in  a  separate  report.  The  charts  in  Figures  3a  and 
3b  diagram  relationships  and  design  details  to  aid  in  the 
explanation  of  CEMES'  design  and  operation  in  the  following 
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CEMES  FRONT-END  ON  HP  9000  MODEL  520  MINICOMPUTER 


CEMES  Graphic  Display 


Front-End 
Blackboard  Files 

Blackboard  File: 

Diagnostic  Messages 
Treatment  Messages 
Logistics  Messages 
Message  Messages 
Sensor  Hardware  Status 
Treatment  Hardware  Status 
Vital  Signs 

Operator  Supplied  Signs 
Diagnoses  Text  File 
Treatments  Text  File 
Logistics  Text  File 
Messages  Text  File 


Event-  Based 

Inter- Program  Communications 
Protocol 


Communications  and  File 
Transfer  Control  Program 


Master  Control  Program 
System  Startup 
System  Shutdown 
Program  Backup 
Text  File  Maintenance 
System  Interface 
Change  Blackboard 
Cause  Events 
Suspend  Operation 
Output  Hardcopy 

System  Interaction 
Interface  Menus 


Sensoj^  Sub  system 


Effector  Subsystem 


Sensor  Data 
Processing 
Program 


Treatment 
Hardware  Control 
Program 


Sensor  I/O 
Control 


Biomedical 
Sensors  and 
Simulators 


1  ' 

1  Treatment  . 

I  Hardware  1 

|  I/O  Control  1 

1  | 

1  1 

|  Electronic  IVs  i 

1  | 

I  | 

1  i 

FIGURE  3a.  CEMES  front-end  detailed  organizational  chart. 
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CEMES  CORE  PROGRAM  ON  SYMBOLICS  3640  LISP  MACHINE 
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FIGURE  3b.  CEMES  expert  system  detailed  organizational  chart. 
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sections.  Figures  3a  and  3b  also  have  served  as  master  plans 
for  integrating  the  various  subsystems. 

The  double  lines  and  arrows  in  Figures  3a  and  3b  represent 
communications  capabilities  and  directions  between  subsystems 
within  each  computer.  The  single  lines  and  arrows  represent 
communications  and  data  flow  between  the  two  computers  and  the 
operator.  Note  that  the  connection  between  the  two  computers 
is  via  a  RS232  line,  a  portion  of  which  appears  in  each  figure. 
This  separation  is  necessary  because  the  double  lines  represent 
communications  implemented  differently  than  the  communications 
represented  by  single  lines.  Communications  represented  by 
double  lines  are  not  accessible  to  the  operator  during  normal 
operation  of  the  CEMES  system. 

The  double-lined  communications  also  represent  the  style 
of  programming  used  for  CEMES.  CEMES  was  developed  using  an 
object-oriented  programming  style.  This  style  involves 
programming  in  terms  of  independent  chunks,  or  objects,  that 
directly  correlate  with  the  major  aspects  and  divisions  of  the 
programming  problem. 6  This  division  is  straightforward  with 
CEMES,  each  subsystem  being  programmed  as  its  own  object  or 
collection  of  objects. 

The  LISP  language  Implementation  on  the  Symbolics  3640 
provides  direct  object-oriented  programming  constructs.  The 
communication  protocol  used  between  objects  is  referred  to  as 
message  passing.  Therefore,  the  subsystem  objects  programmed 
on  the  Symbolics  3640  use  a  message-based  inter-  and  intra¬ 
object  communications  protocol.  However,  the  BASIC  language 
Implementation  on  the  HP  9000  does  not  provide  for  a  direct 
object-oriented  programming  style.  It  is  a  multitasking 
language  which  was  used  to  simulate  the  features  of  object- 
oriented  programming.  This  was  accomplished  by  coding  an 
object  as  a  complete  program  ( 1 . e . ,  task)  and  using  the  event 
semaphores  provided  by  the  HP  BASIC  language  for  message 
passing. 7 


6  An  in-depth  explanation  of  object-oriented  programming, 
message  passing,  and  its  importance  as  a  general  programming 
style  is  outside  the  scope  of  this  report.  The  reader  is 
referred  to  Stefik  and  Bobrow  (1986)  for  a  discussion  and 
additional  references  concerning  object-oriented  programming. 

7  Event  semaphores  generally  are  used  to  signal  control  or 
availability  of  shared  devices  in  multitasking  environments. 

For  example,  two  programs  running  concurrently  may  need  to  use 
a  single  device  such  as  a  printer.  Both  programs  cannot  access 
the  device  concurrently.  Semaphores  are  used  as  signals  between 
the  programs  to  indicate  the  availability  of  shared  devices. 
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It  Is  important  to  not©  there  are  two  blackboards 
diagrammed  in  Figures  3a  and  3b.  The  core  program  blackboard 
object  appearing  in  the  Symbolics  3640  portion  of  CSMES  ( 1 . e . , 
Figure  3b,  the  actual  expert  system  portion)  represents  the 
blackboard  shown  in  the  general  design  in  Figure  1 .  The 
blackboard  shown  for  the  HP  9000  programs  (Figure  3a)  is  a 
duplicate  with  some  additional  support  data  files.  This  type 
of  design  was  selected  to  facilitate  the  speed  and  efficiency 
of  communications  between  the  subsystems  on  the  two  computers 
and  avoid  a  potential  bottleneck  that  might  degrade  real-time 
operation.  The  communications  programs  for  each  computer 
maintain  congruency  between  the  two  blackboards  by  transmitting 
only  those  data  required  or  changed.  The  scheduling  of  the 
communications  is  controlled  by  the  expert  system  portion  of 
CEMES  on  the  Symbolics  machine. 
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The  CEMES  expert  system 


The  primary  operational  portion  of  CEMES  is  the  expert 
system  that  resides  on  the  Symbolics  3640  LISP  machine.  As 
noted  in  the  previous  section,  the  CEMES  expert  system  is 
composed  of  the  diagnostics,  trend,  and  management  subsystems 
(Figures  1  and  3b)  that  act  as  independent  knowledge  sources 
with  the  blackboard  serving  as  a  shared  data  repository. 
However,  CEMES  does  not  use  a  strict  blackboard  control 
strategy.  In  a  prototypical  blackboard-based  expert  system 
(such  as  Hearsay),  each  knowledge  source  operates  independently 
and  simultaneously  based  on  the  information  on  the  blackboard. 
Knowledge  sources  attempt  to  complete  their  tasks  automatically 
when  the  appropriate  information  is  entered  on  the  blackboard. 
Their  sole  means  of  communication  are  through  information 
posted  on  the  blackboard.  Knowledge  sources  compete  for 
processing  time  with  conflicts  being  arbitrated  through  a 
central  scheduling  mechanism. 


CEMES,  however,  has  a  strict  process  control  loop  that 
activates  each  knowledge  source  ( i . e . ,  subsystem)  at  the 
appropriate  time  when  its  task  must  be  completed.  The  flow  of 
information  ( i . e. .  data)  only  is  mediated  through  the 
blackboard.  In  addition,  the  CEMES  blackboard  is 
unidimensional  in  that  it  contains  "raw"  data  (vital  signs), 
intermediate  results  (system  status  data),  and  final  results 
(diagnoses  and  display  messages).  There  is  no  time  or  other 
second  dimension  as  is  the  usual  case  for  systems  based  on  a 
blackboard  control  architecture. 


The  process  control  loop  is  relatively  straightforward  and 
largely  based  on  the  requirements  for  medical  diagnosis  and 
treatment  (from  Landon,  1986).  The  process  control  loop  is 
diagrammed  in  Figure  4.  It  should  be  noted  easily  that  the 
subsystem  organization  in  terms  of  objects  and  collections  of 
objects  (Figure  3b)  directly  corresponds  with  the  principal 
steps  of  the  process  control  loop  (Figure  4).  This  reflects 
the  object-oriented  programming  style  and  maintains  a  direct 
and  visible  relationship  between  program  function  and  code 
structure.  Each  step  in  the  process  control  loop  will  be 
explained  along  with  the  tasking  assignments  of  the  various 
subsystems  for  each  step  in  the  loop. 


CEMES  first  obtains  the  necessary  biomedical  data  through 
the  front-end  sensor  subsystem.  At  this  Phase  I  interim  stage, 
the  collection  of  vital  sign  data  is  simulated  through  a  menu- 
driven  system  interaction  program  that  is  part  of  the  front-end 
master  control  program  on  the  HP  9000.  The  data  are  entered 
manually  and  recorded  on  the  front-end  blackboard  for  transfer 
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to  the  expert  system  when  requested.  These  vital  sign  data 
ourrently  are  limited  to  blood  pressure, , heart  rate,  and 
respiration  rate  ( i. e. .  the  key  yital  signs  for  hemorrhagic 
shook) . 

Following  data  oolleotion,  the  first  step  for  the  expert 
system  is  to  determine  a  diagnosis  with  respect  £o  shock  or  any 
related  cardiovascular  problems  (or  to  indicate  if  the  casualty 
is  stable,  should  that  be  the  case).  The  diagnostics  subsystem 
is  tasked  with  completing  this  step.  Although  the  diagnostic 
procedures  currently  are  limited  to  using  blood  pressure,  heart 
rate,  and  respiration  rate,  at  later  phases  this  step  will  have 
to  be  accomplished  with  whatever  data  the  front-end  can  provide 
( i . e . f  degraded  mode  functioning).  The  diagnostics  subsystem 
also  retains  all  knowledge  representations  of  the  various 
possible  diagnoses  and  their  treatment  models.  The  form  of 
these  representations  will  be  covered  in  a  later  section. 
However,  it  must  be  noted  that  treatment  models  are  "attached" 
to  each  diagnosis,  so  that  once  a  diagnosis  is  made,  the 
appropriate  treatment  model  is  known. 

The  next  step  is  to  determine  a  diagnostic  trend  within 
the  trend  subsystem.  This  is  accomplished  both  by  examining 
relationships  between  successive  diagnoses  and  analyzing  the 
vital  sign  history  of  the  casualty.  The  trend  analysis  can 
have  three  directions  (improving,  deteriorating,  or  unchanging) 
and  two  magnitudes  (catastrophic  or  gradual)  for  a  combined 
total  of  five  trend  outcomes  ( i. e. .  the  unchanging  direction 
has  no  magnitude).  The  trend  subsystem  also  maintains  a 
medical  history  of  vital  sign  data,  diagnostic  results,  and 
trend  results. 
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After  determination  of  the  trend,  a  logistical  analysis  is 
completed  by  the  logistics  object  within  the  management 
subsystem.  The  logistical  analysis  currently  involves 
signaling  the  hookup  of  IV  infusion  units  when  required, 
tracking  the  administration  and  depletion  of  IV  fluid,  and 
providing  indications  for  IV  bag  replacement  as  necessary.  For 
example,  the  treatment  model  attached  to  the  current  diagnosis 
may  require  IV  fluid  infusion  when  no  IV  lines  have  been 
established.  The  logistical  analysis  senses  this  problem, 
provides  the  necessary  messages  to  signal  the  medic  or 
physician  that  an  IV  line  is  required,  and  inhibits  other 
subsystems  from  assuming  that  an  appropriate  treatment  is  being 
administered  until  the  logistical  conditions  necessary  for  the 
treatment  are  met.  The  logistics  object  uses  system  hardware 
representations  attached  to  the  management  subsystem  to 
accomplish  its  task.  At  present,  there  is  only  one 
representation  which  is  used  to  model  IV  fluid  infusion  units. 
During  later  phases,  representations  will  be  added  for  sensor 
units  to  aid  in  degraded  mode  determinations  using  a 
prediagnostic  logistical  analysis  in  the  erroneous-data-check 
object  shown  on  Figure  3b. 

The  last  principal  step  in  the  process  control  loop  is  the 
selection  of  a  treatment  regimen  by  the  manager  object  in  the 
management  subsystem.  The  appropriate  treatment  model  was 
determined  previously  during  the  diagnosis  step.  The  treatment 
selection  step  actually  involves  selection  of  the  appropriate 
treatment  parameters,  which  currently  is  limited  to  adjustment 
of  IV  fluid  infusion  rate.  The  guidelines  for  parameter 
selection  are  represented  by  the  treatment  models.  That  is, 
the  rate  of  fluid  administration  is  dependent  upon  the 
diagnosis  (from  diagnostics  and  the  knowledge  representation), 
the  rate  of  deterioration  or  improvement  (from  the  trend 
analysis),  and  whether  the  appropriate  logistical  conditions 
have  been  met  (from  logistics). 

The  process  control  loop  is  concluded  by  updating  all 
medical  history  accounts  in  the  various  subsystems  maintaining 
such  accounts  and  providing  the  proper  signals  to  effect  the 
treatments  or  update  the  graphics  display  as  required.  The 

process  control  loop  then  recycles  after  a  1-minute  interval. 

1 

The  process  control  loop  itself  is  mediated  through  inter- 
and  intrasubsystem  object-oriented  message  passing.  The  method 
( i . e . .  code)  containing  the  control  loop  currently  resides  as 
part  of  the  manager  object  in  the  management  subsystem.  This 
loop  also  serves  as  point  of  entry  and  exit  for  external 
control  of  CEMES  on  the  Symbolics  LISP  machine.  At  this 
interim  phase,  once  the  loop  is  entered,  it  can  only  be  exited 
through  a  machine-dependent  interrupt.  A  more  appropriate 
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BP  Systolic 


interface  to  the  system  (the  system  interface  object  in  Figure 
3b)  will  be  included  at  a  later  phase. 

Knowledge  representation 

The  principal  representational  technique  used  in  CEMES 
expert  system  is  the  frame.  Each  diagnosis,  treatment,  and 
system  component  model  is  represented  using  a  frame-based  form. 
Each  treatment  model  frame  is  attached  to  a  complementary 
diagnosis  model  frame,  which  are  related  via  a  network.  The 
system  component  models  are  independent  frames. 

The  general  relationships  between  the  various  diagnostic 
outcomes  are  expressed  in  terms  of  a  general  network  which 
represents  a  diagnostic  decision  matrix  for  values  of  blood 
pressure  and  pulse.  This  diagnostic  matrix/network  is  shown  in 
Figure  5.  The  nodes  of  the  network  in  Figure  5  represent  the 
nine  outcomes  from  combining  systolic  blood  pressure  and  pulse 
vital  sign  values  in  terms  of  their  relations  to  normal.  That 
is,  whether  systolic  blood  pressure  and  pulse  are  within  the 
normal  range,  higher  than  normal,  or  lower  than  normal. 8  The 


PULSE 

LOW  NORMAL  HIGH 


FIGURE  5.  Knowledge  representation  decision  matrix  network. 


8  Normal  ranges  have  been  defined  in  terms  of  a  well- 
conditioned  male  approximately  19  years  old.  Blood  pressure 
would  normally  be  120/80  with  a  systolic  range  of  90-160. 
Pulse  would  normally  be  75  with  a  range  of  70-100. 
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specifics  nodes  of  this  network  that  define  shock  have  been 
outlined.  The  nine  nodes  in  this  network  serve  as  a  basis  for 
the  detailed  representation  of  the  diagnostic  outcomes  in  terms 
of  frames.  Each  node  in  the  network  is  in  turn  represented  by 
one  or  more  diagnostic  model  frames  that  contain  the  details 
for  each  diagnostic  outcome. 

Since  the  principal  tasking  of  CEMES  is  the  diagnosis  and 
treatment  of  hemorrhagic  shock,  the  various  levels  of 
hemorrhagic  shock  have  been  separated  into  a  more  detailed 
network  as  shown  in  Figure  6.  Note  that  there  are  two  basic 
types  of  relationships  between  the  hemorrhagic  shock  and  normal 
nodes,  better/worse  and  much-better/much-wor se .  These 
relationships  aid  in  determining  trends  as  a  casualty's 
condition  changes  from  one  shock  class  to  another.  Each  class 
of  shock  has  its  own  diagnostic  model  frame. 

While  the  networks  serve  as  a  type  of  meta-representation, 
the  actual  technique  of  knowledge  representation  in  CEMES  is 
the  frame.  The  form  of  each  diagnostic  model  frame  is  shown  in 
Figure  7.  The  features  of  each  diagnostic  frame  include  a 
group  of  slots  for  diagnostic  analysis,  a  group  of  slots  for 
trend  analysis,  a  single  slot  that  identifies  the  treatment 
model  attached  to  that  particular  diagnosis,  an  active  flag 
slot  to  indicate  whether  or  not  that  diagnosis  frame  has  been 


NORMAL 


MW/MB  -  relation  Is  much  worse  or  much  better 

FIGURE  6.  Knowledge  representation  network  for  shock. 
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Injury-name:  <name-of-in jury> 

Diagnostics : 

Essential-properties: 

Auxiliary-properties: 

Trends : 

Properties : 

Getting-worse : 

Getting-better : 

Relations : 

Worse-than: 

Much-worse- than: 

Better- than: 

Much-better  - than:  <name-of-injury> 
Current-direction: 

Range:  (worse, much- worse, better, much- better, 

unchanged ) 

Default:  unchanged 

Treatment-procedure:  <procedure-name> 

Is-active : 

Range:  (yes, no) 

Default:  no 

Severity- index: 

Range :  (1-10) 


(<property,range>, . . . ) 
(< pr op erty, range >, . . . ) 


(<property,direction>,  .  .  .  ) 
(  <property, direction>,  .  .  .  ) 

<name-of-injury> 

<name-of~injury> 

<narae-of“lnjury> 


FIGURE  7.  Diagnostic  model  frame  organization. 


Injury- name:  Cl ass -3- hemorrhagic- shock 

Diagnostics  : 

Essential-properties:  (bp-sys  80-89, pulse  121-180, 

capillary-blanch  positive, mental- status 
confused-lethargic) 

Auxiliary-properties:  (resp  29-33, urine  5-19) 

Trends : 


Properties: 

Getting-worse : 

Getting-better : 

Relations : 

Worse- than : 

Much-worse- than: 

Better- than: 

Much-better- than: 

Current-direction:  unchanged 

Treatment-procedure:  Class-3-shock- treatment 

Is-active:  yes 

Severity-index:  8 


(bp-sys  <, pulse  >) 

(bp-sys  >, pulse  <) 

Class-2-hemorrhagic-shock 
Class- 1 -hemorrhagic-shock 
Class-4-hemorrhagic-shock 
None 


FIGURE  8.  Class  3  hemorrhagic  shock  diagnostic  frame. 
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activated,  and  a  severity  index  slot  to  indicate  the  relative 
severity  of  that  diagnosis  on  a  scale  of  1  to  10.  An  actual 
diagnostic  frame  for  class  3  hemorrhagic  shock  is  provided  in 
Figure  8  to  show  the  types  of  information  that  are  entered  into 
the  various  frame  slots. 

The  diagnostics  slots  provide  information  related  to  the 
activation  of  the  frame  as  the  current  diagnosis.  The  various 
vital  signs  and  other  properties  and  the  appropriate  ranges 
necessary  for  the  frame's  activation  are  listed.  In  the  case 
of  a  vital  sign  where  numerical  values  are  available,  a 
numerical  range  is  given.  In  other  cases,  a  qualitative  word 
or  phrase  appropriate  to  the  sign  is  provided.  The  inference 
procedure  then  uses  this  information  when  determining  if  the 
frame  should  be  activated. 

The  trends  slots  provide  both  property  lists  for  trend 
directions  and  pointers  that  represent  the  network  relations 
shown  in  Figures  5  and  6.  The  trend  properties  provide 
directional  Indicators  for  various  vital  sign  data  with  respect 
to  a  general  improving  or  deteriorating  trend.  The  trend 
inference  procedures  use  this  information  to  determine  trend 
direction  and  magnitude.  The  trend  relations  slots  provide 
names  of  other  diagnostic  frames  as  appropriate  for  their 
relationship  according  to  the  networks. 

The  treatment  procedure  slot  contains  the  name  of  the 
appropriate  treatment  model  frame  for  the  diagnosis.  The 
treatment  models  also  are  represented  by  frames  in  the  general 
form  shown  in  Figure  9®  All  treatment  procedures  currently 
simulated  by  CEMES  are  based  on  IV  fluid  administration. 
Therefore,  all  current  treatment  frames  are  of  the  type  "IV- 
based"  and  have  the  particular  frame  organization  as  shown  in 
Figure  9®  The  treatment  model  frame  includes  a  group  of  slots 
representing  the  particular  properties  of  the  IV  treatment,  a 
trend  adjustments  group  of  slots,  and  an  active  flag  slot  to 
indicate  whether  or  not  the  treatment  frame  currently  is 
activated.  An  example  treatment  frame  for  class  3  hemorrhagic 
shock  is  shown  In  Figure  10. 

The  properties  slots  in  the  treatment  frame  contain 
general  information  of  relevance  to  IV-based  treatments.  The 
number  of  IV  units  required  is  stated  explicitly.  The  IV-rate- 
rang©  provides  practical  lower  and  upper  bounds  in  cc/hr  for 
the  administration  of  fluid  for  the  particular  diagnosis. 
Absolut©  lower  and  upper  bounds  currently  are  limited  by 
equipment  considerations  (0  and  6000,  respectively).  XV- 
additives  currently  are  not  implemented  at  this  interim  phase, 
but  will  include  lists  of  drugs  and  dosages  appropriate  for  the 
treatment.  IV-felood  is  a  simple  indicator  of  whether  or  not  a 
transfusion  is  required.  CEMES  currently  does  not  manage  blood 


Treatment- name :  <name-of-treatment> 

Type:  IV-based 

Properties : 

IV-units-required: 

Range :  (0,1,2) 

Default:  1 

IV-rate-range :  <min,max> 

Range :  ( 100-6000) 

IV-additives:  (<additive,dosage>, . . .) 

IV-blood : 

Range:  ( indicated , not-indicated ) 

Trend-ad jus tments : 

Unchanged:  <direction , amount> 

Worse:  <direction, amount> 

Much-worse:  <direction , amount> 

Better:  <direc tion , amount > 

Much-better:  <direction , amount> 

Is-active : 

Range:  (yes, no) 

Default:  no 


FIGURE  9*  Hemorrhagic  shock  treatment  procedure  frame 
organization , 


Treatment-name:  Cl  ass- 3 -shock- treatment 

Type:  IV-based 

Properties : 

IV-units-required:  2 

IV-rate-range:  (3000,6000) 

IV-additives s  <not  yet  determined> 

IV-blood:  indicated 

Trend-adjustments: 

Unchanged:  (+  1000) 

Worse:  (+  1000) 

Much-worse:  (+  1500) 

Better:  (-  1000) 

Much-better:  (-  1000) 

Is-active:  yes 


FIGURE  10.  Class  3  hemorrhagic  shock  treatment  frame, 

transfusion.  The  IV-blood  indicator  Is  based  on  the  average 
amount  of  volume  loss  necessary  to  produce  the  various  classes 
of  hemorrhagic  shock. 
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The  treatment  frame’s  trend-adjustments  slots  provide 
modifiers  for  IV  rates  based  on  the  trend  direction  and 
magnitude.  The  management  of  fluid  administration  not  only 
depends  on  the  diagnosis,  but  also  on  trends.  These  modifiers 
aid  in  the  adjustment  of  the  actual  cycle  by  cycle  fluid  flow 
rates.  A  sign  indicates  fluid  flow  should  be  increased  by 

the  stated  amount,  while  a  »-*  sign  indicates  a  decrease. 

The  various  hardware  system  components  in  CEMES  also  are 
represented  by  frames.  Unlike  the  frames  for  diagnoses,  the 
hardware  frames  generally  are  independent  and  not  related 
through  networks  or  other  means.  Presently,  only  automated  IV 
fluid  administration  units  are  represented  in  CEMES. 9  These 
units  have  the  frame  organization  shown  in  Figure  11.  The  Is- 
attached  slot  is  an  indicator  for  attachment  to  the  casualty. 
The  Is-functioning  slot  has  been  included  for  degraded  mode 
operation.  It  will  change  depending  upon  whether  the  IV  unit 
is  functioning  properly,  not  functioning  ( e. g. .  not  attached  or 
out  of  fluid),  or  if  there  is  a  problem  ( e . g . .  actual  fluid 


Type:  IV-fluid-unit 

Is-attaohed : 

Range:  (yes, no) 

Default:  no 

Is-functioning: 

Range:  ( yes , no , problem) 

Default:  no 

Location: 

Range:  (arm, neck, leg, other) 

Relative- start- time : 

Range:  (0-1440) 

Absolute- start- time : 

Range:  (0-1440) 

Renewals : 

Range:  (0-50) 

Fluid-remaining: 

Range:  (0-1000) 

Administration- rate : 

Range:  (0-3000) 

Additives : 


FIGURE  11.  IV  treatment  unit  frame  organization. 


9  An  IV  administration  unit  is  assumed  to  consist  of  an  IV 
bag  containing  appropriate  solution  (usually  Ringer’s  lactate), 
tubing  and  needle  for  fluid  delivery,  and  an  automated  pump 
that  generates  fluid  flow  at  the  rate  determined  by  CEMES. 
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flow  does  not  match  signalled  fluid  flow,  indicating  a  possible 
blockage).  The  absolute  start  time  slot  provides  the  cycle 
number  when  the  IV  unit  successfully  was  attached  to  the 
casualty,  while  the  relative  start  time  slot  indicates  the 
cycle  when  the  current  IV  bag  was  started  on  this  IV  unit. 
Renewals  indicate  the  number  of  IV  bags  that  have  been 
delivered  on  the  IV  unit  exclusive  of  the  current  bag.  Fluid- 
remaining  and  administration-rate  are  self-explanatory  and  are 
given  in  cc  and  cc/hr  measurements. 

Ill  £e.r.  ftfl  P.  g.-PX  P.  g.ed.M  r_£s 

The  inference  procedures  used  by  the  CEMES'  expert  system 
are  different  in  both  technique  and  use  from  the  process 
control  loop.  Whereas  the  process  control  loop  governs  the 
order  of  task  completions  in  CEMES,  the  inference  procedures 
govern  the  matching  of  the  vital  sign  data  to  the  diagnostic 
frames  in  order  to  determine  an  appropriate  diagnosis  at  each 
cycle . 

The  basic  inference  model  used  in  CEMES  is  a  simple 
forward  chaining  using  a  matching  procedure  for  the  various 
diagnostics  properties  in  the  diagnostic  model  frames.  The 
procedure  first  attempts  to  match  the  blood  pressure  and  pulse 
vital  signs  against  the  constraints  specified  in  the  meta- 
representation  network  shown  in  Figure  5.  Since  all  nodes  in 
this  network  can  be  uniquely  identified,  a  successful  match  at 
this  step  often  will  identify  a  particular  diagnostic  frame  for 
activation.  However,  in  some  cases,  particularly  those  nodes 
identifying  hemorrhagic  shock,  there  are  multiple  diagnostic 
frames,  only  one  of  which  can  be  activated.  Any  frames  that 
cannot  be  viable  candidates  after  this  step  are  eliminated  from 
further  consideration.  Those  that  remain  are  entered  on  a 
temporary  candidate  list  for  further  analysis. 

When  the  general  network  analysis  is  insufficient  for  a 
unique  frame  identification,  the  inference  procedure  attempts 
to  match  all  available  data  against  the  diagnostic  constraints 
in  the  essential  properties  list  of  each  diagnostic  frame.  If 
two  or  more  frames  still  can  be  activated  after  this  matching, 
the  auxiliary  property  lists  are  checked.  If  a  unique  frame 
still  cannot  be  identified,  the  severity  indices  are  checked 
and  the  most  severe  diagnostic  frame  then  is  activated. 

The  inference  procedure  of  selecting  a  unique  frame  does 
not  exhaustively  examine  each  frame’s  properties  in  turn  ( 1 .  e_.  t 
a  depth  search).  The  various  vital  signs  (and  other  symptoms 
to  be  considered  at  later  stages)  have  been  ordered  in  terms  of 
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their  medical  importance  with  respect  to  hemorrhage  and 
shock* 10  The  current  value  of  the  most  important  vital  sign  is 
first  checked  across  the  diagnostic  constraints  for  the 
remaining  frames  in  the  candidate  list  f i. e. ,  a  breadth 
search).  Those  frames  that  fail  the  match  are  eliminated  from 
further  consideration.  The  next  most  important  sign  then  is 
checked  across  the  remaining  frames,  etc.,  until  a  single  frame 
remains,  which  then  is  activated.  If  multiple  frames  remain 
after  all  signs  and  symptoms  have  been  checked,  then  the  frame 
with  the  highest  severity  index  is  activated.  If  the  severity 
indices  match,  a  frame  is  selected  at  random. 

The  check  and  eliminate  scheme  of  inference  is  shown  in 
flow-chart  form  in  Figure  12.11  This  particular  form  of 
inference  was  selected  due  to  its  anticipated  capability  for 
completing  a  diagnosis  during  degraded  mode  operation.  That 
is,  any  prototypical  forward  chaining  inference  procedure  would 
collapse  as  less  and  less  information  was  available  in  the 
database  ( i. e. .  matches  would  be  impossible  to  obtain  or  the 
knowledge  base  would  have  to  be  expanded  to  include  frames 
accounting  for  all  possible  available  combinations  of  the 
various  signs  and  symptoms).  The  elimination  technique  has 
both  an  advantage  of  speed  and  a  robustness  when  various  vital 
sign  data  are  unavailable.  That  is,  the  matching  procedure  for 
unavailable  data  results  in  no  eliminations  from  the  current 
candidate  list.  If  the  most  important  vital  sign  data  are 
available,  elimination  down  to  a  single  candidate  will  be 
fairly  quick  and  avoid  all  sorts  of  confirmatory  procedures  and 
mechanisms. 

In  addition  to  diagnostic  inference,  CEMES  also 
incorporates  trend  inference  mechanisms  to  determine  the 
current  diagnostic  trend.  Recall  there  are  three  directions 
(improving,  deteriorating,  and  unchanging)  and  two  magnitudes' 
(catastrophic  and  gradual)  for  a  trend  outcome.  The  conditions 


10  The  current  ordering  is  blood  pressure,  pulse,  and 
respiration  rate.  Additional  signs  and  symptoms  will  be 
entered  in  the  list  as  required  in  later  stages.  Note  this 
ordering  is  established  only  for  diagnosis.  Some  signs  (e.  g. , 
urine  output)  are  not  essential  for  diagnosis,  but  do  have 
significant  meaning  for  treatments  or  other  aspects  of  CEMES 
operation. 

11  This  elimination  scheme  was  described  by  Tversky  (1972) 
in  a  study  of  human  choice  processes.  He  referred  to  it  as  the 
"elimination  by  aspects"  choice  process.  A  complete 
theoretical  treatment  of  various  choice  and  selection  processes 
can  be  found  in  Landon  (1983). 
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for  trend  direction  are  provided  by  the  activated  diagnostic 
frame  in  terms  of  properties  and  relations. 

The  trend  inference  generally  is  straightforward.  The 
previous  cycle's  diagnosis  (kept  by  the  trend  object)  is 
checked  to  see  if  it  is  the  same  as  the  current  active 
diagnosis.  If  it  is,  then  the  vital  signs  are  checked  by  the 
elimination  method  described  above  against  the  trend  property 
lists  to  determine  direction.  It  is  generally  the  case  that 
each  vital  sign  has  opposite  indications  for  an  improving  or 
deteriorating  direction,  and  so  the  general  direction  can  be 
determined  quickly.  However,  medical  requirements  sometimes 
dictate  that  more  than  one  sign  (usually  at  least  systolic 
blood  pressure  and  pulse)  satisfy  the  trend  constraints  before 
a  direction  is  confirmed.  In  such  cases,  the  elimination 
inference  procedure  continues  until  the  required  number  of 
constraints  are  failed  by  either  the  improving  or  deteriorating 
direction.  If  both  the  improving  and  deteriorating  directions 
fail,  then  the  trend  direction  defaults  to  unchanging. 


current 

candidate  list  start  importance  list 


FIGURE  12.  Check  and  eliminate  inference  procedure. 
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Trend  magnitude  is  determined  through  straightforward 
algorithmic  techniques  accomplished  concurrently  with 
directionality  checking.  Catastrophic  magnitude  is  indicated 
if  the  current  vital  sign  value  deviates  from  the  previous 
vital  sign  value  or  the  median  of  the  previous  five  values  by 
10  or  more.  Gradual  magnitude  is  indicated  by  a  strict 
increasing  or  decreasing  ordering  of  the  vital  sign  values  over 
the  last  five  cycles  if  such  an  ordering  does  not  meet  the 
catastrophic  magnitude  constraints.  If  the  direction  indicated 
is  unchanged,  then  magnitude  is  irrelevant.  Conversely,  if 
neither  catastrophic  nor  gradual  magnitude  is  found  (as 
indicated  by  failure  to  meet  the  algorithmic  requirements), 
then  the  direction  is  unchanged. 

In  the  cases  where  the  previous  ( i. e. .  last  cycle's) 
activated  diagnostic  frame  is  not  the  same  as  the  current 
active  frame,  the  previous  diagnostic  frame  is  checked  against 
the  network  relations  of  the  current  active  diagnosis.  If  a 
match  is’  found,  then  the  trend  is  established  by  which  category 
of  match  was  obtained  ( i. e. .  worse-than  indicates  a  gradual 
deterioration,  much-worse- than  indicates  a  catastrophic 
deterioration,  etc.  See  Figure  7).  If  a  match  is  not  found, 
then  the  trend  defaults  to  unchanged.  That  is,  if  the  current 
active  diagnostic  frame  has  no  relation  with  the  previous 
active  diagnostic  frame,  then  there  is  no  trendy  A  trend 
cannot  be  established  in  a  single  cycle. 

The  final  type  of  inference  made  by  CEMES  is  the  selection 
of  a  treatment.  Currently,  this  consists  of  selection  of  an 
appropriate  IV  fluid  infusion  rate  if  an  IV  is  indicated  by  the 
active  treatment  model  frame.  The  selection  of  an  infusion 
rate  has  three  principle  steps.  First,  the  active  treatment 
model  frame  is  checked  to  see  if  an  IV  is  required.  If  so,  the 
IV  infusion  frames  are  checked  to  see  if  the  required  units  are 
attached  and  functioning  (which  was  determined  by  the  logistics 
analysis).  If  they  are  not  attached,  a  message  is  printed  on 
the  graphics  display  informing  the  medic  or  physician  the 
casualty  requires  an  IV  line  be  established  for  treatment. 
Attached  but  malfunctioning  units  will  be  handled  by  the 
logistics  analysis  when  degraded  mode  operation  is  included  in 
CEMES.  Next,  assuming  attached  and  functioning  IV  infusion 
units,  the  IV-rate-range  slot  of  the  active  treatment  frame  is 
examined.  If  the  current  administration  rate  is  less  than  the 
minimum  specified  by  the  range,  the  rate  is  increased  to  the 
minimum,  otherwise  the  rate  is  not  changed.  Last,  the  trend 
outcome  is  examined  and  the  appropriate  adjustment  to  the  rate 
is  made.  If  the  adjustment  causes  the  rate  to  go  outside  of 
the  rate  bounds,  the  rate  is  changed  to  the  minimum  or  maximum 
as  required. 
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The  CEMES  front-end 


The  process  control  loop  and  subsystem.,  tasking 

The  front-end  portion  of  the  CEMES  system  resides  on  the 
HP  9000  minicomputer.  The  front-end  is  responsible  for 
controlling  or  simulating  all  data  input/output  for  the  expert 
system  portion  on  the  Symbolics  LISP  machine.  As  noted  in  the 
previous  section  "CEMES  general  design,"  the  front-end 
primarily  is  composed  of  the  sensor  and  effector  subsystems. 
However,  these  subsystems  have  not  been  completed  at  this 
interim  stage.  Instead,  their  functions  are  simulated  within 
the  Master  Control  Program  shown  on  Figure  3a.  Presently, 
those  portions  of  the  front-end  that  are  operational  include 
the  Master  Control  Program,  the  Graphics  Display  Generation  and 
Control  Program,  and  the  Communications  and  File  Transfer 
Control  Program.  As  in  the  expert  system  portion  of  CEMES,  the 
front-end  is  governed  by  a  process  control  loop  that 
coordinates  the  various  programs  that  comprise  the  front  end. 

Despite  the  use  of  a  process  control  loop,  the  front-end 
systems  are  nearly  totally  independent  of  each  other  and  are 
much  truer  to  a  pure  blackboard  type  of  expert  system 
architecture.  The  only  form  of  interprograra  communications  is 
signals  indicating  when  the  various  types  of  information  on  the 
blackboard  have  changed.  This  provides  a  more  orderly  approach 
to  blackboard  file  access  by  each  program.  The  reason  for  this 
is  to  maintain  control  over  access  to  a  single  device  (IjlSj., 
the  blackboard  file)  by  multiple  programs  running  concurrently 
in  a  multitasking  environment. 

The  CEMES  front-end  process  oontrol  loop,  diagrammed  in 
Figure  13,  is  implemented  within  the  Communications  and  File 
Transfer  Program  on  the  HP  9000.  This  program  cycles  in 
response  to  signals  received  from  the  CEMES  expert  system.  The 
signals  function  as  either  data  requests  or  information 
updates.  Data  request  signals  identify  data  the  expert  system 
wants  transmitted  this  cycle.  For  example,  vital  signs  are 
requested  every  cycle.  Information  updates  can  contain 
graphics  display  updates  and/or  effector  control  information. 
Data  request  signals  always  precede  information  updates 
the  expert  system  requests  new  data,  processes  it,  and  returns 
its  solutions  to  the  front-end  for  implementation). 

Upon  receiving  a  data  request  signal  from  the  expert 
system,  the  Communications  and  File  Transfer  Control  program 
obtains  the  requested  data  from  the  blackboard  through  a  simple 
file  access.  Note  that  in  an  operational  CEMES  unit,  the 
sensor  and  effector  subsystems  continuously  will  be  updating 
the  front-end  blackboard.  At  present,  blackboard  data  updates 
are  being  simulated  through  a  menu-driven  manual  data  entry 
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Wait  for  data  request  from  expert  system 


Obtain  Vital  sign  or  other  requested 
data  from  blomedloal  sensors,  effectors,  etc. 

Transmit  new  data  to  expert  system 


Wait  for  display  updates  and  other  control 
information  to  be  sent  by  expert  system 


Update  graphio  display 

Generate  appropriate  control  signals 
for  treatment  effectors 


Reoycle 


FIGURE  13.  CEMES  front-end  process  control  loop. 


system  that  Is  part  of  the  Master  Control  Program.  The 
operation  of  the  menu-driven  system  will  be  explained  in  the 
subseotion  "The  master  oontrol  program." 

The  Communications  and  File  Transfer  Control  Program  then 
sends  the  requested  data  to  the  expert  system  through  the  HP- 
serlal-lo  object,  whloh  controls  communications  for  the  expert 
system.  The  communications  and  data  transfer  between  the 
front-end  and  the  expert  system  consists  of  a  simple  ASCII  file 
transfer  using  a  RS232  line  between  the  HP  9000  and  Symbolics 
3640.  At  present,  no  special  communications  protocols  (e.g. f 
Remit,  Xmodem)  or  networking  Ethernet)  other  than  X-on 

and  X-off  are  used  to  accomplish  file  transfers.  In  addition, 
the  oomnunlcation  is  synchronous  with  the  HP-serial-io  object 
on  the  Symbolics  3640  aoting  as  the  controller.  Asynchronous 
communications  capabilities  and  the  required  processing 
interrupt  meohanlsms  will  be  inoluded  for  Phase  II  to  implement 
operator  interaction. 

After  sending  the  requested  data,  the  Communications  and 
File  Transfer  Control  Program  enters  a  wait  state  until  updated 
information  is  received  from  the  expert  system.  The  updated 
information  consists  of  ohanges  to  the  graphics  display  and 
other  oontrol  signals  describing  the  treatment  regimen  during 
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the  next  cycle.  When  the  updated  information  is  received,  the 
Communications  and  Pile  Transfer  Control  Program  enters  the  new 
information  on  the  blackboard  and  sends  the  appropriate 
messages  informing  the  other  front-end  programs  that  certain 
information  on  the  blackboard  has  changed.  Currently,  the 
front-end  simply  updates  the  graphics  display  as  all  effector 
actions  are  being  simulated  on  the  display.  At  later  stages, 
the  effector  subsystem  will  generate  the  necessary  control 
signals  to  change  IV  fluid  infusion  rates  or  drug 
administration  rates  as  necessary. 


After  processing  the  updated  information,  the 
Communications  and  File  Transfer  Program  enters  another  waiting 
state  until  the  expert  system  restarts  the  process  control  loop 
through  a  request  for  data.  Of  course,  when  implemented,  the 
sensor  and  effector  subsystems  will  continue  to  sample  vital 
signs  and  effect  treatments  while  "waiting*  for  the  next  cycle. 
Although  not  currently  planned,  at  advanced  stages  of  CEMES' 
development,  a  mechanism  may  be  included  in  the  front-end  so  it 
can  interrupt  the  expert  system  when  a  particularly  serious 
condition  oocurs  (such  as  ventricular  fibrillation). 


The  graphic  display 

The  graphic  display  is  generated  and  controlled  by  the 
Graphics  Display  Generation  and  Control  Program.  The  graphic 
display  provides  a  means  for  visually  displaying  the  status  of 
CEMES  and  its  various  operations  from  cycle  to  cycle.  The  task 
of  the  Graphics  Display  Generation  and  Control  Program  is  to 
maintain  congruency  between  the  information  in  the  blackboard 
and  the  information  on  the  graphio  display.  An  example  of  the 
graphic  display  is  provided  in  Figure  1H.  It  should  be  noted  a 
display  of  this  complexity  may  or  may  not  be  included  in  a 
field  operational  CEMES  system.  This  particular  graphic 
display  design  was  implemented  to  provide  all  the  necessary 
information  to  aid  in  CEMES*  design  and  testing.  There  are 
five  major  areas  of  the  display,  each  set  off  from  the  other 
and  suitably  labeled. 

The  vital  signs  display  area  contains  the  most  recent 
vital  sign  data  ( i . e . .  it  may  not  be  the  current  vital  signs 
data,  which  is  defined  as  the  data  last  sent  to  the  expert 
system) .  Recall  that  the  sensor  subsystem  will  obtain  vital 
signs  continuously  and  independently.  Therefore,  there  will 
always  be  some  lag  between  the  most  recent  data  and  the  current 
data.  However,  since  the  normal  cycle  time  is  quite  short  in 
relation  to  meaningful  physiological  changes,  the  effect  on 
accurate  diagnosis  will  be  nonexistent  or  very  minimal.  Note 
that  provisions  have  been  made  on  the  display  for  some  vital 
signs  that  aren’t  yet  being  used  by  the  expert  system. 
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FIGURE  14.  CEMES  graphic  display  example. 


The  elapsed  time  display  area  provides  an  indication  of 
the  time  the  casualty  has  been  attached  to  the  system.  This 
time  is  displayed  digitally  in  hours  and  minutes.  A  "golden 
hour"  also  has  been  provided  that  ticks  off  minutes  in  an 
analog  fashion  by  filling  in  portions  of  the  circle  with  solid 
wedges.  The  golden  hour  has  been  included  primarily  for 
demonstration  purposes  since  the  first  hour  of  emergency 
treatment  often  is  the  most  critical.  At  later  stages,  the 
elapsed  time  area  will  include  the  absolute  start  time,  the 
current  real  time,  and  the  amount  of  time  attached  to  the 
system  ( i.  e. .  the  difference  between  the  absolute  start  time 
and  the  current  real  time). 

The  system  status  display  area  is  where  the  expert  system 
displays  various  messages  having  to  do  with  the  casualty's 
diagnosis,  the  preferred  treatment  regimen,  logistical 
indicators,  and  any  additional  messages  deemed  necessary. 

These  four  classes  of  messages  are  separated  and  displayed 
under  appropriate  labels  that  define  display  subareas  within 
the  system  status  area.  The  various  messages  are  color  coded 
white,  green,  yellow,  or  red  depending  upon  the  type  of 
message.  The  default  display  color  is  white,  with  system  OK 
messages  in  green,  cautionary  or  advisory  messages  in  yellow, 
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and  severe  or  warning  messages  in  red.  Advisory  and  warning 
messages  also  are  aocompanied  by  additional  visual  oues  in  the 
form  of  a  header  (as  in  the  "ALERT"  header  shown  in  the  Figure 
14  example)  and  auditory  cues  with  differing  frequencies  and 
temporal  characteristics. 


The  hardware  status  display  area  provides  a  pictorial 
display  of  the  location  and  status  of  the  various  sensor  and 
effector  units  that  have  been  attached  to  the  casualty.  The 
icons  and  labels  for  each  hardware  item  are  color  coded  to 
provide  visual  cues  as  to  their  status.  Green  indicates  the 
hardware  is  OK  and  functioning  properly.  Yellow  indicates  a 
problem  or  a  malfunction.  Red  indicates  the  hardware  item  is 
not  functioning  (for  whatever  reason). 


The  hardware  status  display  area  in  the  example  (Figure 
14)  shows  various  devices  that  serve  as  examples  for  what  could 
be  included  in  an  operational-front  end. 12  There  are  four  EKG 
limb  leads  appropriately  labeled  RA,  LA,  RF,  and  LF.  Note  that 
lead  RA  is  malfunctioning  with  a  message  to  that  effect 
appearing  in  the  logistics  subarea  of  the  system  status  area. 

An  automated  BP  cuff  is  attached  to  provide  blood  pressure 
measurements.  The  PMC  label  represents  a  personal  monitor  and 
communicator  which  provides  heart  rate  and  respiration  rate. 13 
An  ear  oximeter  also  has  been  attached  in  this  example.  This 
particular  casualty  has  had  two  IV  units  attached,  one  of  which 
is  getting  low  on  fluid. 


The  last  display  area  is  the  trend  graph  at  the  top  of  the 
display.  This  graph  provides  a  chart  upon  which  the  various 
vital  sign  data  can  be  plotted  for  a  visual  indication  of  how 
those  signs  have  changed  across  time.  The  example  in  Figure  14 
shows  systolic  blood  pressure  and  heart  rate.  The  values 
plotted  are  absolute  values,  with  the  scale  shown  at  the  left 
of  the  graph.  The  intermittent  vertical  lines  represent  10 
minute  intervals  in  real-time.  At  this  interim  stage,  the 
Graphics  Display  Generation  and  Control  Program  only  can 
display  systolic  blood  pressure  and  heart  rate  on  the  trend 
graph.  The  capability  for  displaying  all  the  various  vital 
signs  in  various  combinations  will  be  added  at  a  later  time. 


12  The  example  in  Figure  14  is  not  meant  to  indicate  that 
all  of  the  equipment  shown  is  either  necessary  or  will  be 
assumed  to  part  of  an  operational  CEMES  front-end.  There  are 
both  scientific  and  practical  questions  that  must  be  addressed 
with  regard  to  how  to  noninvasively  monitor  certain 
physiological  signs. 

13  This  wristwatch  type  device  is  being  developed  under 
contract  and  currently  exists  in  brassboard. 
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Note  the  trend  graph  has  room  to  display  1  hour's  worth  of 
data.  This  shows  the  graph's  particular  configuration  for  the 
first  hour  of  operation.  After  the  first  hour,  the  horizontal 
scale  on  the  graph  condenses  to  represent  2  hours'  worth  of 
data  ( i . e . ,  the  number  of  vertical  lines  doubles).  The  last 
hour's  data  is  redrawn  on  the  new  scale  with  new  data  being 
graphed  on  the  end  of  the  previous  hour.  That  is,  there  is 
always  as  much  data  as  is  available,  or  at  least  1  hour's  worth 
of  data  with  the  new  data  being  tacked  on  as  received. 

The  master  control  program 

The  principal  program  for  the  CEMES  front-end  at  present 
is  the  Master  Control  Program  shown  on  Figure  3a.  This  program 
provides  all  the  various  menu-driven  capabilities  for 
simulation,  control,  and  bookkeeping  on  the  front-end.  An 
organizational  chart  of  the  various  menus  available  in  the 
Master  Control  Program  is  provided  in  Figure  15.  The  specific 
menus  themselves  are  shown  in  Figure  16  exactly  as  they  appear 
on  the  console  CRT  and  serve  as  labels  for  the  softkeys 
provided  on  the  HP  9000  keyboard.  A  push  of  the  appropriate 
softkey  initiates  the  particular  action  indicated  by  the  key's 
label.  An  explanation  of  the  Master  Control  Program  will 
proceed  through  an  explanation  of  what  can  be  done  within  each 
menu. 1 4 


Demo 

menu 


Main  menu 


System 
Interaction 
menu 


Text  file 

maintenance 

menu 


Change 

blackboard 

menu 


FIGURE  15.  Master  Control  Program  menu  hierarchy. 


14  This  subsection  is  not  intended  as  a  user's  or 
instructional  manual  for  the  operation  of  the  CEMES  front-end, 
even  though  the  explanation  of  the  various  menu  selections  of 
the  Master  Control  Program  will  provide  a  basic  knowledge  of 
how  to  operate  the  front-end  at  this  interim  stage.  A  complete 
operational  manual  may  be  written  for  CEMES  at  a  future  date. 
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The  main  menu  provides  a  starting  point  for  selecting  the 
particular  activity  to  be  accomplished.  The  "System  Startup" 
selection  begins  execution  of  the  front-end  programs  (as 
opposed  to  loading  and  running  the  Master  Control  Program  which 
requires  some  knowledge  of  the  HP  9000  minicomputer).  Once 
booted  and  started,  the  front-end  enters  a  waiting  state  for 
the  initial  data  request  from  the  expert  system.  Selecting  the 
"System  Shutdown"  option  performs  the  opposite  task  by  stopping 
operation  of  the  front-end  programs  and  resetting  the  HP  9000 
for  normal  computer  operations.  "File  Backup"  provides  a  means 
for  automatically  generating  floppy  disk  backups  of  all  the 
front-end  programs  and  files  that  normally  reside  on  the  HP 
9000's  internal  hard  disk.  A  full  backup  requires  three 
properly  formatted  5.25-inch  floppy  disks,  each  of  which  is 
inserted  into  the  internal  floppy  disk  drive  on  cues  provided 
by  the  backup  program.  The  backup  program  returns  to  the  main 
menu  upon  completion.  The  last  three  selections  on  the  main 
menu  provide  branches  to  the  other  menus  of  the  Master  Control 
Program . 

The  main  menu  "Txt_file  Maint"  selection  branches  to  the 
text  file  maintenance  menu.  This  menu  is  used  to  control 
operations  with  respect  to  the  four  text  files  that  are  part  of 
the  front-end  blackboard  (see  Figure  3a).  These  four  text 
files  contain  the  various  text  messages  that  appear  in  the 
system  status  portion  of  the  graphic  display.  The  expert 
system  signals  the  display  of  the  various  messages  in  the  four 
subareas  of  the  system  status  display  area  through  appropriate 
codes  that  are  transmitted  to  the  front-end  on  each  cycle.  The 
Graphics  Display  Generation  and  Control  Program  interprets  the 
various  codes,  retrieves  the  proper  messages  from  the  text 
files,  and  generates  the  appropriate  graphics  for  the 
display . 1 5 

Text  file  maintenance  operations  proceed  by  first 
selecting  a  file  to  work  on  (the  "Select  File"  choice  on  the 
menu),  and  then  completing  whatever  actions  are  desired.  The 
"Add  Text"  selection  branches  to  a  routine  for  adding  new  text 
messages  to  the  file.  The  "Output  Hardcopy"  selection  produces 
a  listing  of  all  text  messages  currently  in  the  file  on  the 
internal  thermal  printer  of  the  HP  9000.  The  "Change  Text" 
selection  branches  to  a  routine  allowing  changes  to  be  made  to 
existing  text  messages. 


15  The  text  message  codes  are  the  actual  information 
stored  in  the  blackboard  file  after  being  parsed  from  the 
updated  information  file  by  the  Communications  and  File 
Transfer  Control  Program.  That  is,  the  only  place  where  the 
text  messages  appear  in  readable  form  is  on  the  graphic  display 
or  in  a  hardcopy  dump  of  the  text  file. 
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FIGURE  16.  Master  Control  Program  menus. 


As  can  be  inferred  from  the  names  of  the  four  text  files, 
each  corresponds  to  messages  that  are  displayed  in  the  four 
subareas  of  the  system  status  display  area.  Each  text  file  can 
contain  up  to  400  different  messages  with  no  more  than  52 
characters  per  message  (including  spaces  and  punctuation).  The 
operation  of  the  expert  system  determines  the  types  of  messages 
entered  into  each  file. 

The  "Cemes  Demo”  selection  on  the  main  menu  branches  to 
the  demonstration  menu.  The  demonstration  menu  is  used  when 
generating ,  changing,  and  conducting  demonstrations  of  the 
CEMES  system.  A  demonstration  consists  of  normal  CEMES  cycles 
with  a  recycle  rate  of  20  seconds  rather  than  1  minute.  This 
is  to  allow  reasonable  casualty  scenarios  to  be  presented  in 
shorter  times.  The  demonstration  mode  of  operation  also 
requires  modified  versions  of  the  Communications  and  File 
Transfer  Control  Program  and  the  Graphics  Display  Generation 
and  Control  Program.  In  addition,  the  demonstration  operates 
by  automatically  retrieving  new  blackboard  data  (^tet ,  vital 
signs,  etc.)  from  a  file  rather  than  using  manual  input. 
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To  initiate  a  demonstration  of  CEMES,  the  "Demo  Setup” 
selection  is  first  made  (the  expert  system  portion  having  been 
started  independently  in  demonstration  mode  on  the  Symbolics 
machine).  This  prepares  the  front-end  programs  for  operation 
and  establishes  a  wait  state.  After  opening  or  other  remarks, 
the  "Start  Demo"  selection  can  be  made  and  the  demonstration 
will  run  until  data  in  the  demonstration  file  is  exhausted, 
when  the  demonstration  will  be  shut  down  automatically.  if  the 
demonstration  needs  to  be  stopped  prematurely  for  some  reason, 
the  "Demo  Shutdown"  selection  can  be  made. 

The  other  selections  on  the  demonstration  menu  are  used  to 
operate  on  the  demonstration  data  file.  The  "Create  Demo" 
selection  branches  to  a  routine  for  the  generation  of  a  new 
demonstration  data  file.  Various  prompts  are  provided  as 
required  to  aid  in  the  entering  of  the  data.  The  "Change  Demo" 
selection  branches  to  a  routine  for  changing  a  specific  cycle’s 
data  in  an  existing  demonstration  data  file.  The  "Hardcopy 
Demo"  selection  provides  a  printed  output  of  the  current 
demonstration  data  file  on  the  internal  thermal  printer  of  the 
HP  9000,  It  should  be  noted  at  present  only  one  demonstration 
data  file  can  exist  at  any  time.  Future  provisions  may  be  made 
for  multiple  demonstration  data  files  so  different  casualty 
scenarios  can  be  demonstrated  without  going  through  an  involved 
"Create  Demo"  process. 

The  "System  Interact"  selection  on  the  main  menu  branches 
to  the  system  interaction  menu.  The  system  interaction  menu  is 
used  when  simulating  the  sensor  and  effector  subsystems  during 
a  normal  test  run  of  the  CEMES  system.  The  "Output  Hardcopy" 
selection  provides  either  a  ’snapshot’  printed  output  on  the 
internal  thermal  printer  of  the  data  currently  in  the  front-end 
blackboard,  or  a  color  graphics  plot  of  the  current  graphic 
display  screen  on  an  HP  7475A  six-pen  plotter  (see  Appendix  A) 
that’s  attached  to  the  HP  9000.  The  "Cause  Events"  and 
"Suspend  Opertn"  selections  on  the  system  interaction  menu 
currently  are  not  programmed.  They  are  included  for  more 
advanced  mechanisms  to  test  CEMES  operation  at  later  stages. 

The  "Change  Blckbrd"  selection  of  the  system  interaction 
menu  branches  to  the  change  blackboard  menu  which  provides 
selections  for  simulating  the  collection  of  new  data  on  the 
front-end.  This  is  where  manual  entering  of  vital  signs  and 
other  data  is  accomplished  during  a  test  run  of  the  CEMES 
system.  The  basic  procedure  for  using  this  menu  is  to  first 
select  the  category  of  change  to  be  made.  The  selection  enters 
a  prompted  procedure  for  entering  the  types  of  changes 
allowable  in  that  category.  After  all  changes  have  been  made 
in  the  various  categories,  the  "Do  it"  selection  is  made.  This 
starts  a  routine  that  makes  the  changes  permanent  in  the  front- 
end  blackboard  file.  That  is,  changes  that  are  entered  do  not 
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take  effect  until  the  "Do  it"  selection  is  made.  Once  "Do  it" 
is  started,  the  changes  in  the  blackboard  will  show  up  on  the 
graphic  display. 

The  "Vital  Signs"  selection  of  the  change  blackboard  menu 
branches  to  a  routine  that  prompts  for  new  vital  sign  data  to 
be  entered.  Any  or  all  of  the  currently  programmed  vital  signs 
can  be  changed.  The  "Treat  Hardware"  selection  branches  to  a 
routine  that  allows  changes  to  be  made  to  the  available 
treatment  hardware  ensemble.  This  includes  signaling  that  an 
IV  unit  is  attached  and  indicating  whether  the  hardware  is 
functional  or  not  (even  though  the  expert  system  cannot  yet 
deal  with  attached,  but  malfunctioning  hardware).  The  "Sensor 
Hardware"  selection  is  used  to  make  similar  changes  for  the 
available  sensor  hardware  ensemble.  These  three  selections  are 
the  principal  types  of  changes  that  are  made  during  operation 
and  testing  of  CEMES. 

The  "Diagnose ," "Treat , ""Logist , "  and  "Mess"  selections  are 
for  changing  message  entries  that  are  displayed  in  the  system 
status  area  of  the  graphic  display.  These  selections  were 
included  to  test  the  operation  of  text  message  display,  and 
should  not  be  selected  during  an  operational  test  of  CEMES.  To 
do  so  could  create  a  mismatch  between  the  messages  the  expert 
system  thinks  are  being  displayed  and  the  messages  actually 
being  displayed,  giving  a  false  impression  that  the  expert 
system  has  malfunctioned.  These  selections  will  be  deleted  at 
a  later  stage. 
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Phase  II  objectives 


The  Phase  II  exploratory  development  of  CEMES  has  four 
major  objectives:  design  the  necessary  operator  interfacing  for 
CEMES*  query/response  operation,  expand  CEMES  diagnostics  to 
include  operation  under  CBR  contamination,  expand  CEMES  for 
operation  under  degraded  modes,  and  design  and  construct  a  more 
realistic  front-end  using  biomedical  simulators  and  automated 
IV  units. 

Following  Phase  II,  it  is  anticipated  a  proof  of  concept 
operational  CEMES  will  be  available  for  full  demonstrations  of 
medical  expert  system  operation  in  the  domain  of  emergency 
medicine  for  shock.  Data  input  will  be  accomplished 
automatically  when  possible  or  through  query  when  necessary. 
Full  casualty  simulation  of  biomedical  signals  will  be 
available  through  appropriate  patient  simulators  or  other 
instrumentation.  IV  infusion  treatment  will  be  demonstrated 
through  automated  IV  infusion  units. 
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Summary 


This  report  has  described  interim  progress  concerning  the 
exploratory  development  of  a  combat  emergency  medicine  expert 
system  (CEMES).  The  principal  aspects  of  the  design  and 
operation  of  CEMES  have  been  documented.  CEMES  can  diagnose 
and  simulate  IV  treatment  for  all  classes  of  hemorrhagic  shock. 
Additional  mechanisms  for  drug  treatments,  diagnosis  under 
contamination,  and  degraded  mode  operation  have  been  included, 
but  are  not  fully  operational  at  this  stage. 
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APPENDIX  A 


Manufacturers  list 


Hewlett-Packard  Company- 
Building  5 
4700  Bayou  Blvd. 
Pensacola,  FL  32503 

Symbolics,  Inc. 
Department  803 
555  Virginia  Road 
Concord,  MA  017*12 
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